SharePoint 2010 : Using Enterprise Search (part 3) - Modifying Authoritative Pages and Search Metadata

3. Modifying Authoritative Pages and Search Metadata

3.1. Configuring Authoritative Pages

For many years, people who work with electronic data have recognized that information workers spend a considerable amount of time searching for information to complete a task. And they spend that time not just using search engines, but also in a number of locations, such as file shares, intranet websites, customer records management systems, and so on. Although people do manage to find useful information, it may not be what they are originally looking for, and the time spent searching for information could be costing companies a great deal of money in wasted time. Implementing an enterprise search solution that indexes content and provides a suitable user interface can solve some of these productivity issues. An important part of the solution is to ensure that the search results are ranked according to relevancy and the user is provided with more than a simple search box to enter a query. This is where authoritative pages help, because they indicate links to content that are more important than others, and creating search metadata provides a filtering mechanism when searching for content.

The aim of authoritative pages is to categorize Web pages or sites into one of four authoritative levels. In the SharePoint 2010 Central Administration website, these levels are

• Most authoritative pages

• Second-level authoritative pages

• Third-level authoritative pages

• Sites to demote

You can use two sets of cmdlets in Windows PowerShell, as explained in Table 12-4, to complete similar tasks that rank Web pages or sites.

The following examples and sample output show how to create, retrieve, amend, and delete authoritative pages.

# Assign www.contoso.msft as one of the most authoritative pages
New-SPEnterpriseSearchQueryAuthority -Url "http://www.contoso.msft" `
   -SearchApplication $searchapp -Level 0;

Url                                       Level      Status
---                                       -----      ------
http://www.contoso.msft/                  0          StatusNotInitialized

# List all sites that are assigned an authoritative page level
Get-SPEnterpriseSearchQueryAuthority -SearchApplication $searchapp;

Url                                       Level      Status
---                                       -----      ------
http://intranet.contoso.msft/             0          StatusNotInitialized
http://www.contoso.msft/                  0          StatusNotInitialized

# Change the authoritative page level to Second-level authoritative pages
Set-SPEnterpriseSearchQueryAuthority -Identity "http://intranet.contoso.msft" `
   -SearchApplication $searchapp -Level 1;
# Remove the assignment of an authoritative page level from a site
Remove-SPEnterpriseSearchQueryAuthority "http://www.contoso.msft" -sea $searchapp;

					  

Confirm
Are you sure you want to perform this action?
Performing operation "Remove-SPEnterpriseSearchQueryAuthority" on Target
"http://www.contoso.msft/".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

# Check that the authoritative page level for the site was removed.
Get-SPEnterpriseSearchQueryAuthority -SearchApplication $searchapp;

Url                                        Level     Status
---                                        -----     ------
http://intranet.contoso.msft/              1         StatusNotInitialized

The following example and sample output show how to create and retrieve information about demoted sites.

New-SPEnterpriseSearchQueryDemoted -Url "http://oldintranet.contoso.msft"`
   -SearchApplication $searchapp;

Url                                                       CrawledDocumentCount
---                                                       --------------------
http://oldintranet.contoso.msft/                          4

					  

Enterprise search, as it indexes different content sources, discovers new properties, which are known as crawled properties, such as Author and Modified By. Properties are also known as metadata, and you can use the values of properties to limit the number of search results returned. However, the number of crawled properties can be enormous, and if each crawled property were exposed, it would result in a very busy and probably unusable search interface. SharePoint Server can be configured to identify those crawled properties that are important for the business needs, which in turn can be used in the search experience. This subset of crawled properties is referred to as managed properties. Metadata mapping is the process of mapping crawled properties to managed properties.

Crawled properties are grouped in metadata categories, based on the type of content source indexed. Therefore, categories help give meaning to the crawled properties, whose names are sometimes lengthy and obtuse, as well as aid in helping find the crawled property that you want to map to a managed property. In Windows PowerShell, a number of cmdlets are associated with objects to manage metadata crawled and managed properties, as shown in Table 5.

Each Search Service Application maintains a list of crawled properties. The following example shows how to count the number of crawled properties maintained by the Search Service Application referenced by the variable $seachapp.

@(Get-SPEnterpriseSearchMetadataCrawledProperty -Search $searchapp).count

The following examples and sample output show the number of crawled properties by category and the number of crawled properties that are mapped to managed properties grouped by category.

Get-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $searchapp | `
   sort categoryname, name | group -property CategoryName;

					  

Count Name                      Group
----- ----                      -----
   57 Basic                     {136, 77, 137, 78...}
    2 Business Data             {320, 321}
   14 Mail                      {122, 123, 124, 133...}
    3 Notes                     {322, 324, 323}
   22 Office                    {189, 186, 317, 182...}
   53 People                    {15, 16, 17, 18...}
  159 SharePoint                {201, 297, 295, 200...}
   51 Web                       {144, 113, 145, 114...}

Get-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $searchapp | `
   where {$_.isMappedToContents -eq $True} | sort categoryname, name | `
group -property CategoryName | sort count -Descending;

					  

Count Name                       Group
----- ----                       -----
   67 SharePoint                 {337, 291, 239, 238...}
   12 Web                        {113, 114, 115, 116...}
   10 Office                     {389, 388, 181, 177...}
    4 People                     {18, 20, 22, 48}
    3 Basic                      {137, 135, 101}
    1 Mail                       {125}

The following example and sample output shows the crawled properties “Manager” found in the “People” category.

$crawlprop = Get-SPEnterpriseSearchMetadataCrawledProperty `
   -SearchApplication $searchapp | `
   where {($_.categoryname -eq "People") -and ($_.name -like "*Manager*")};
$crawlprop;

Name               : urn:schemas-microsoft-com:sharepoint:portal:profile:Manager
CategoryName       : People
Propset            : 00110329-0000-0110-c000-000000111146
IsMappedToContents : False
VariantType        : 31

					  

The VariantType property indicates the data type of the crawled property. To map a crawled property to a managed property, both properties must be of the same data type. The New-SPEnterpriseSearchMetadataManagedProperty cmdlet uses the –Type parameter to specify the data type for managed property. Unfortunately, the values for –Type do not match the values for the VariantType property. The list of supported data types, with their associated VariantType values and –Type parameters, are shown in Table 6.

Therefore, before you can automate the creation of a managed property from a crawled property, you need to create a script to translate values between the VariantType property and the –Type parameter. This can easily be achieved by using a hash table, also known as a dictionary, which allows you to store data in a key-value pair association, as shown in the following example.

$MetaDataTypes=@{31 =1;20=2;5=3;64=4;11=5;65=6}

Therefore, when you use $MetaDataTypes[$crawlprop.VariantType] where $crawlprop.VariantType has a value of 31, the output will be 1. This technique is used in the following example, which lists a function that, given a crawled property, will create a new managed property and map the crawled property to the managed property. The function accepts the following four input parameters.

• $PropName The word or words that will uniquely identify the crawled property. Thus, you do not need to know the fully qualified name of a crawled property to use this function; you can simply enter part of the crawled property name.

• $PropCat The category for the crawled property. The name of a crawled property can occur from different connectors. The category can be used to uniquely identify the crawled property.

• $ManName The name for the new managed property.

• $search The first few characters that will uniquely identify the name of the search application.

The function checks that only one crawled property exists and that the crawled property is not already mapped to an existing managed property before creating a managed property and creating the mapping.

Function Set-ManagedPropFromName
([string] $PropName, [string] $PropCat, [string] $ManName, [string] $search)
{
  # Create a hashtype to convert VariantType to -Type values for data types.
  # Supported data types:Text, Integer, Decimal, Date and Time, Yes/No, Binary Data
  $MetaDataTypes = @{31=1; 20=2; 5=3; 64=4; 11=5; 65=6}
  # Get Search Service Application object from value in input parameter $search
  $searchapp = Get-SPEnterpriseSearchServiceApplication | `
   where {$_.Name -like $search+"*"};
  # Get crawled property object that matches crawled category and crawled property
  # name provided from input parameters $PropCat and $PropName
  $crawledProp = Get-SPEnterpriseSearchMetadataCrawledProperty -Search $searchapp `
   -ErrorAction SilentlyContinue | `
   where {($_.CategoryName -eq $PropCat) -and ($_.Name -like "*"+$PropName+"*")};
  # If no crawled property identified or more than one crawled property identified
  # using name from input parameter $PropName, write error message
 If (@($crawledProp).count -ne 1)
 {
   Write-Host "Error: Crawled Property: $PropName had: " + `
    @($crawledProp).count + "occurrences.";
 } else {
    Write-Host "Crawled Property: $crawledProp found";
    # Check that property not already mapped to managed property
    If ($crawledProp.IsMappedToContents)
    {
        Write-Host "Error: Crawled Property property: $PropName already mapped.";
    } else {
       Write-Host "Check whether Managed Property already Exists";
       # Check whether Managed Property already exists.
       $ManProp = Get-SPEnterpriseSearchMetadataManagedProperty $ManName `
        -SearchApplication $searchapp -ErrorAction SilentlyContinue;
        If ($ManProp)
        {
          Write-Host "Error: Managed Property: $ManName already exists.";
        } else {
          Write-Host "Create Managed Property: $ManName"
          $ManProp = New-SPEnterpriseSearchMetadataManagedProperty $ManName `
          -SearchApplication $searchapp -Type $MetaDataTypes[$CrawledProp.VariantType] `
          -Description "$ManName : $PropCat" -Retrievable $True `
          -EnabledForScoping $True;
          Write-Host "Create Mapping";
          New-SPEnterpriseSearchMetadataMapping -CrawledProperty $crawledProp `
           -ManagedProperty $ManProp -SearchApplication $searchapp;
        }
    }
  }
} # End of Function Set-ManagedPropFromName

					  

Set-ManagedPropFromName -PropName "Manager" -PropCat "People" '
   -ManName "ManagerAD" -search "Search";
Crawled Property: 24 found
Check whether Managed Property already Exists
Create Managed Property: ManagerAD
Create Mapping
CrawledPropset             : 00110329-0000-0110-c000-000000111146
CrawledPropertyName        : urn:schemas-microsoft-com:sharepoint:portal:
                             profile:Manager
CrawledPropertyVariantType : 31
ManagedPid                 : 407

Property mappings associated with a managed property must be deleted before the managed property is deleted. The following example finds the mapping associated with the ManagerAD managed property and removes the mapping before deleting the managed property.

get-SPEnterpriseSearchMetadataMapping -SearchApplication $searchapp `
   -ManagedProperty "ManagerAD" | Remove-SPEnterpriseSearchMetadataMapping
   -Confirm:$false;
Remove-SPEnterpriseSearchMetadataManagedProperty "ManagerAD" `
   -SearchApplication $searchapp -Confirm:$false;